Notification system of deviation from predefined conditions

ABSTRACT

The present invention includes a healthcare system for capturing and maintaining patient healthcare records and employing information in the records to proactively alert hospital workers to a condition that places patient health at risk.

This is a continuation of U.S. patent application Ser. No. 13/836,259,filed Mar. 15, 2013, entitled NOTIFICATION SYSTEM OF DEVIATION FROMPREDEFINED CONDITIONS, which claims the benefit of U.S. patentapplication Ser. No. 61/672,740, filed Jul. 17, 2012, entitledNOTIFICATION OF PATIENT RISK CONDITIONS, which are hereby incorporatedby reference herein in their entireties.

TECHNICAL FIELD AND BACKGROUND OF THE INVENTION

The present disclosure relates generally to healthcare systems forcapturing and maintaining patient healthcare records and employinginformation in the records to proactively alert hospital workers to acondition that places patient health at risk.

A healthcare provider, such as a hospital, typically admits and treatssome number of patients on a daily basis. Upon admission to thehospital, a healthcare worker can create a record that includes medicaland/or personal information associated with each patient. Depending uponthe size of the hospital, the healthcare provider can create andmaintain a very large number of these medical records, and such recordsare typically created and then stored as an electronic medical record(EMR) in a healthcare system. Depending upon the size of the hospital,the healthcare system can operate in a single computational device, suchas a personal computer or other device, or the healthcare system can bedistributed in a plurality of computational devices that are connectedto over a network (healthcare system network or simply the Network) toone or more servers which operate to, among other things, capture andstore the electronic medical records. In addition to including patientmedical information, an EMR can also include the identity and location(hospital room) of a hospital bed to which a patient is assigned.Hospital beds are available that include physical and physiologicalsensors which are connected over the Network to the Healthcare System.Information collected by the sensors can be processed at the bed by acontroller or can be transmitted to the Hospital System for processingand storage in an EMR associated with the patient currently occupyingthe bed.

While physiological measures of a patient's health can be employed toproactively alert healthcare workers of an impending patient healthcrisis, healthcare systems do not currently operate to proactively alerthealthcare workers to a condition at the bed, such as a hospital bedconfiguration, which may be unsatisfactory for a given patient based onthe patient's condition or risk.

SUMMARY OF THE INVENTION

The present invention includes a notification system that takes intoaccount the condition or risk factor of a given patient. The benefits toa patient in a healthcare system that can operate to proactively warnhealthcare workers of an adverse patient condition are apparent. Theability to identify which patients may suffer possible, future adversehealth events, such as a stroke or congestive heart failure, can eitherextend or save a patient's life.

In one form of the invention, a notification system includes a patientsupport and a patient support monitoring system that is configured todetect and monitor when the patient support's configuration isunsuitable for a given patient based on the patient's condition or riskfactor(s) and then generate a notification of an unsatisfactoryconfiguration at the patient support.

In one aspect, the patient's condition or risk factor is determined orselected, for example, by a staff member and then is designated for thatpatient Based on the designated condition or risk factor for thepatient, the patient support monitoring system may automatically selector determine a set of appropriate patient support configurations and/orcriteria, such as side rails up or down, bed exit alarmed, head of bedangle, patient movement, as default configurations and/or criteria forthat patient. Alternately or in addition, the system can have the set ofappropriate patient support configurations and/or criteria entered, forexample, by a caregiver either to override the default or establish thedefault configurations and/or criteria.

In another aspect, the patient support monitoring system may include anetwork interface and one or more sensors in communication with thenetwork interface for detecting the actual configuration and/or criteriaof the patient support. The network interface is in communication with,for example, a hospital network or nurse call station, which receivesthe status or signal(s) of the sensor(s) from the network and comparesthe status or signal(s) to the appropriate patient support configurationand/or criteria to determine if the actual patient support configurationand/or criteria deviate from the appropriate patient supportconfiguration and/or criteria.

In yet a further aspect, when the patient support monitoring systemdetermines that actual patient support configuration and/or criteria ofthe patient support deviate from the appropriate patient supportconfiguration and/or criteria, the patient support monitoring systemwill generate the notification of an unsatisfactory configuration at thepatient support.

For example, the notification may include alerts to staff, for example,including mobile alerts, pop-up displays, for example at the nurse callstation, generate alarms, for example at the patient support,documentation for storage, for example, for reports or for archival,anecdotal, training, or six sigma purposes.

In another aspect, the notification level may be selected. For example,the caregiver or the system itself may select and designate a highpriority notification level, for example, for a high risk factorpatient, a medium priority notification level, for example, for amoderate risk factor patient, and a low priority notification level, forexample, for a low risk factor patient. For example, a high risk factormight be a high risk fall factor.

Before the embodiments of the invention are explained in detail, it isto be understood that the invention is not limited to the details ofoperation or to the details of construction and the arrangement of thecomponents set forth in the following description or illustrated in thedrawings. The invention may be implemented in various other embodimentsand of being practiced or being carried out in alternative ways notexpressly disclosed herein. Also, it is to be understood that thephraseology and terminology used herein are for the purpose ofdescription and should not be regarded as limiting. The use of“including” and “comprising” and variations thereof is meant toencompass the items listed thereafter and equivalents thereof as well asadditional items and equivalents thereof. Further, enumeration may beused in the description of various embodiments. Unless otherwiseexpressly stated, the use of enumeration should not be construed aslimiting the invention to any specific order or number of components.Nor should the use of enumeration be construed as excluding from thescope of the invention any additional steps or components that might becombined with or into the enumerated steps or components.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be best understood by reading thespecification with reference to the following Figures, in which:

FIG. 1 is a diagram of a Hospital Healthcare System;

FIG. 2 is a diagram of an intelligent hospital bed;

FIG. 2A is a schematic of a notification of the present invention;

FIG. 3A is a table of exemplary configurations for a given predefinedcondition;

FIG. 3B is a table of a format of a listing of patients and theirassociated risk type;

FIG. 3C is a table of a patient risk profile showing exemplaryinformation, e.g. risk criteria and configuration, for a given patient;

FIG. 3D is a table of information included in a current bedconfiguration state;

FIG. 4 is a functional block diagram of one embodiment of an eventnotification module;

FIG. 5 is a functional block diagram of one embodiment of a fall riskprocessing client; and

FIGS. 6A and 6B illustrate a logical flow diagram of one embodiment ofthe invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Referring to FIG. 1, the numeral 10 designates a hospital healthcaresystem 10, which is configured to allow it to receive and storeinformation from both healthcare workers and hospital beds. A server 11is shown connected over one or more links to the healthcare system 10network. The server 11 generally operates to capture and maintain astore 12 of patient EMRs, and it has a bed telemetry processing function14 that operates to capture and process information received fromhospital beds connected to the network. The sever 11 also has an eventnotification module 13 that can access information in the EMR store 12and bed telemetry information to determine whether an alert messageshould be sent to a hospital worker or call point connected to thehealthcare system 10. Alternatively, a database management system (DBMS)running on the healthcare system server 11 can operate to maintain thepatient electronic medical records and maintain hospital bedconfiguration status information in a database 15 where the informationcan be accessed by the event notification module 13.

Healthcare organizations, such as a hospital or other care facility,have identified many patient health risks that are directly associatedwith care the patient receives while a resident in the facility. Some ofthese risks are associated with the physiological health of the patient,such as the risk of stroke or heart attack, or the risk of congestiveheart failure for instance. Other types of risk can be associated withthe physical well being of a patient, such as whether a patient is afall risk. Typically upon admission to a healthcare organization, eachpatient can be evaluated to determine the condition of the patientand/or risk factor for the patient, for example, the degree to whichthey are at risk of falling or developing pressure ulcers. Thisevaluation process can include a physical examination, for example, toobserve a patient's motor skills and balance, and/or it can includesimply observing a patient or questioning the patient about theirhealthy history, for example, whether they have had surgery, arediabetic or have poor circulation for other reasons. Regardless of theprotocol employed to quantify the condition or risk, such as a fall riskof a particular patient, a condition or risk can be assigned to eachpatient and entered into a healthcare system, such as the healthcaresystem 10 described earlier, and stored in the patients EMR. A patientsEMR can be easily accessed by a healthcare worker, such as a nurse,nurses aid or physician, in order to determine whether or not a patienthas a condition or risk, such as a risk of falling, and if so the levelor degree to which the patient is at risk. Depending upon the patient'srisk level, the patient's bed can be set up or configured by thehealthcare worker in a manner that can prevent the patient from, forexample, developing pressure sores or accidentally falling out of thebed, or at the bed can be set up so that the patient can more easilyenter and exit the bed.

Referring to FIG. 2, a hospital bed may be configured to include anumber of different types of sensors, and the bed can be connected, overthe network, to a healthcare system. Some bed sensors function to detecta patients weight in one or more positions on the surface of a bed ormovement of the patient on the bed, while other bed sensors may detectwhether or not bed side rails are engaged in a full up position or not.Some bed sensors operate to detect the angle at which one portion of abed meets another portion of the bed, and still other bed sensors candetect physiological characteristics of a patient such as heart rate,respiratory rate, blood pressure to name only three characteristics. Thesensors included in each bed can be connected to a central bed controlmechanism which can operate to receive/capture information from each ofthe sensors, and can process the information prior to transmission overa network link to a healthcare system or send the sensor information tothe healthcare system for processing. The healthcare system can thenprocess the information received from the bed sensors to determinewhether a healthcare worker should be notified of an event, such as apatient having exited their bed or a change in a patient's physiologicalmeasurement such as heart rate, blood pressure or respiratory rate asdetected by bed sensors. Typically, a healthcare system can generate analert in the event that a change to any one or more of a patient'sphysiological measurements is greater than a threshold amount, and thehealthcare system is typically not capable of determining whether thephysiological changes to the patient place the patient at risk of someadverse health event, such as a stroke.

Referring to FIGS. 2 and 2A, a notification system of the presentinvention may include one or more patient supports and a patient supportmonitoring system. In the illustrated embodiment, the patient supportcomprises a hospital bed, but it should be understood that thenotification system of the present invention may include other types ofpatient supports, including stretchers, cots etc. However, for ease ofdescription, reference hereinafter will be made to a hospital bed. Aswill be more fully described below, the present invention includes anotification system that takes into account the condition or risk factorof a given patient.

Referring to FIG. 2A, the patient support monitoring system isconfigured to detect and monitor when the patient support'sconfiguration is unsuitable for a given patient based on the patient'scondition or risk factor(s) and then generate a notification of anunsatisfactory configuration at the patient support. For example,predefined conditions for a given patient risk and/or condition profile,for example, may include different medical conditions (e.g. diabetes,surgery etc.) or clinical conditions of the patient that render thepatient more susceptible to injury (e.g. pressure ulcers), as well asother risk factors include fall risk factors, described more fullybelow. In addition, the patient support monitoring system maybeconfigured to detect and monitor when the patient support'sconfiguration is suitable for a given patient based on the patient'scondition or risk factor(s) and then generate a notification of asatisfactory configuration at the patient support.

The patient's condition or risk factor is determined or selected, forexample, by a staff member and then is designated for that patient.Based on the designated condition or risk factor for the patient, thepatient support monitoring system may automatically select or determinea set of appropriate patient support configurations and/or criteria,such as side rails up or down, bed exit alarmed, head of bed angle,patient movement, as default configurations and/or criteria for thatpatient. Alternately or in addition, the system can have the set ofappropriate patient support configurations and/or criteria entered, forexample, by a caregiver either to override the default or establish thedefault configurations and/or criteria.

For example, the patient support may include a network interface and oneor more sensors in communication with the network interface fordetecting the actual configuration and/or criteria of the patientsupport by way of the sensors. The network interface is in communicationwith, for example, a hospital network or nurse call station, whichreceives the status or signal(s) of the sensor(s) from the network andcompares the status or signal(s) to the appropriate patient supportconfiguration and/or criteria to determine if the actual patient supportconfiguration and/or criteria deviate from the appropriate patientsupport configuration and/or criteria. For a detailed description of asuitable communication system using a bed to transmit such information,reference is made to co-pending application Ser. No. 13/570,934, filedon Aug. 9, 2012, entitled PATIENT SUPPORT APPARATUS WITH IN-ROOM DEVICECOMMUNICATION, which is incorporated by reference herein in its entiretyand commonly owned by Stryker Corporation of Kalamazoo, Mich.

When the patient support monitoring system determines that actualpatient support configuration and/or criteria of the patient supportdeviate from the appropriate patient support configuration and/orcriteria, the patient support monitoring system will generate thenotification of an unsatisfactory configuration at the patient support.For example, the notification may include alerts to staff, for example,including mobile alerts, pop-up displays, for example at the nurse callstation, generate alarms, for example at the patient support, or maygenerate documentation for storage, for example, for reports or forarchival, anecdotal, training, or six sigma purposes.

Optionally, the notification level may be selected. For example, thecaregiver or the system itself may select and designate a high prioritynotification level, for example, for a high risk factor patient, amedium priority notification level, for example, for a moderate riskfactor patient, and a low priority notification level, for example, fora low risk factor patient. For example, a high risk factor might be ahigh risk fall factor.

For example, when a patient has an elevated patient fall risk, thehospital bed configuration may lead to a patient accidentally fallingout of their hospital bed, or falling while attempting to enter theirbed. The formats of and information comprising an illustrative fall risktype, a patient fall risk profile and a current bed configuration arenow described with reference to FIG. 3A-3D respectively. FIG. 3Aidentifies three generic fall risk types (high, medium, low), with eachfall risk type corresponding to a particular minimum hospital bedconfiguration. In this case, the minimum bed configuration specified fora high fall risk type patient requires that three bed rails in the fullup position, the bed height is adjusted to be low and a bed brake is on.These fall risk types can be defined and entered into a healthcaresystem by a healthcare organization based upon a corpus of patient fallrisk information included in EMR's over some period of time.

FIG. 3B is illustrative of one or more patient risk profiles, such asfall risk profiles. All of the profiles can be stored in a patient EMR.A plurality of patients, patient 1 to patient n (with n being an integervalue), are identified, and each of the patients identified is assigneda generic risk type. For example, patient 1 is assigned risk type high,and so forth to patient n which is assigned a low risk type.Alternatively, a patient's risk profile may not include a generic fallrisk type, but instead may be comprised of one or more risk criteria.For example, a fall risk criteria can be identified during an initialpatient fall risk assessment and can include a description of apatient's symptoms (physical and/or physiological) that can affect thepatient's mobility or ambulatory characteristics. Such a fall riskcriteria description can include a description of assistance a patientneeds in order to stand up, sit down and/or walk. The criteriadescription can indicate that a patient cannot stand without beingassisted by a hospital worker, or that they can stand without assistancebut they are not able to walk without the assistance of acane/walker/hospital worker. The criteria description can indicate thatdue to blood pressure issues the patient becomes light headed when theyattempt to stand or that the patient suffers from vertigo. In the eventthat a patients fall risk profile does not include a generic fall risktype, but rather includes one or more fall risk criteria, then a patientfall risk profile may be formatted according to FIG. 3C.

FIG. 3C shows a plurality of patient fall risk profiles each of whichinclude three fields. A first field includes patient identificationinformation, a second field includes fall risk criteria information anda third field includes bed configuration information specificallytailored to each patients fall risk criteria. With respect to patient 1,the fall risk criteria field includes information indicating that thepatient is not able to stand without assistance from a hospital worker,and the corresponding bed configuration profile is then specified toinclude how the bed should be configured to prevent the patient fromaccidentally falling out of the bed and bed configuration informationthat allows the patient to easily enter and exit their bed, which inthis case is that all bed rails should be in the full up position andthe bed should be set to a medium height above the floor.

FIG. 3D is an example format of a current bed configuration record thatis comprised of at least the identity of a patients bed, the identify ofa patient assigned to the bed and their fall risk assessment, and whichincludes the current status of the bed properties (current bed status)as determined by the healthcare system 10 from information/telemetryreceived from the bed sensors. Bed properties in the context of thisdescription refers to, among other things, the number and types of bedrails included on a hospital bed, whether the bed has a height sensor,whether a bed can tilt, whether the bed includes weight sensors and theposition of the weight sensors in the bed. In the preferred embodiment,the current bad property status can be, among other things, adetermination that one or more rails are fully up or down, adetermination as to the height of the bed above floor level and the tiltangle of the bed.

FIG. 4 is illustrative of an event notification module (ENM) 40 that canbe implemented in a server connected to a healthcare network, such asthe healthcare network described with reference to FIG. 1. The ENM 40operates on information comprising a patient EMR, information relatingto a current bed status and a generic fall risk type to determinewhether to generate and send an alarm to a hospital worker or callstation indicating that a patient fall risk is greater than a selectedthreshold. The threshold can be set to a particular numerical value orit can be a minimum bed configuration similar to the minimum bedconfiguration described with reference to FIG. 3A. Alternatively, theENM 40 does not employ the generic fall risk type to determine whetherto generate an alert, but rather uses patient fall risk criteria. TheENM 40 is generally comprised of an event processing function 41, aninput/output message (alarm) processing function 44 and may or may nothave access to a database, such as the database 15 described earlierwith reference to FIG. 1. The event processing function 41 can becomprised of a fall risk processing function or client 42 and otherevent processing clients as necessary for processing different classesof events. The fall risk processing client 42 can operate on, amongother things, information in a patient's EMR and current bedconfiguration information to determine whether to send an alert to acall point or healthcare worker. In the event that an alert is generatedby the event processing function 41, the information in the alert issent to the input/output message processing function 44 which operatesto determine which of one or more healthcare workers or call pointsshould receive the alert. After receiving the alert, the healthcareworker can correct/modify the current bed configuration to at least meetthe minimum hospital bed properties configuration necessary to mitigatethe patient fall risk. Further, the healthcare system can detect thatthe bed configuration is modified/corrected by the healthcare worker tomeet the minimum bed properties configuration and either cancel theearlier transmitted alert or send another alert indicating that thepatient is no longer at risk of falling.

The fall risk processing function or client 42 is now described ingreater detail with reference to FIG. 5. The client 42 is comprised of asubscription module 51, alarm generation logic 52, a store of or accessto a store of minimum bed configuration information 53 per patient fallrisk type, a store or access to a store of patient fall risk profileinformation 54, and a store or access to a store of current bedconfiguration state or information 55. Although the stores 53, 54 and 55are illustrated in FIG. 5 as being local to the client 42, this does nothave to be the case. These stores can be located in temporary storage(buffer memory) associated with the client 42 or these stores can belocated in a main memory in the server, or it can be located in anymemory that is accessible by the client 42 over a local or wide areanetwork. The store(s) described herein can be implemented in any one ora combination of computer data storage technologies, such assemiconductor, magnetic or optical technologies for example. Thesubscription module 51 generally operates to send standard subscriptionrequest messages to one or more servers, connected to a healthcaresystem network, that can store information of interest to the client,such as EMR or bed configuration information. Once a response to asubscription request is received by the module 51, the event processingfunction 41 will automatically start to receive information currentlystored in the record associated with the subscription request. Thisinformation can be for example, information regarding the currentconfiguration state of one or more beds and this state information canbe saved in a store 55 associated with or accessible by the client 42.Alternatively, the client 42 may not subscribe to receive bedconfiguration state information, but rather a healthcare server canperiodically publish current bed configuration state information to someor all of the healthcare clients connected to the healthcare network.

Continuing to refer to FIG. 5, the minimum bed configuration store 53 iscomprised of information similar to that described with reference toFIG. 3A, the patient fall risk profile store 54 is comprised ofinformation similar to that described with reference to either FIG. 3Bor 3C, and the current bed configuration state store 55 is comprised ofinformation similar to that described with reference to FIG. 3D.Finally, the alarm generation logic 52 is comprised of a computerprogram that operates to determine whether or not to generate an alarmbased upon information included in the stores 53, 54 and 55 (oralternative only stores 54 and 55). More specifically, in one embodimentthe logic 52 can operate to examine a patient's fall risk profile,associated minimum bed configuration, and the current bed configurationstate. If the current bed configuration state indicates that the patientis in their bed, the logic proceeds to determine if the current bedconfiguration meets the minimum bed configuration for the patient (i.e.,which rails are up or down, bed heights, etc.). If the current bedconfiguration meets the minimum bed configuration for that patient, thenthe logic 52 does not generate an alert. On the other hand, if thecurrent bed configuration does not meet the minimum bed configurationfor that patient, then an alert is generated. Alternatively, the logic52 only needs to examine the patient fall risk profile 54 if the fallrisk criteria and the bed configuration profile information are storedhere.

The operation of the alarm generation logic 52 will now be describedwith reference to the flow diagram of FIG. 6. While FIG. 6 and thefollowing description are directed to an embodiment in which fall riskcriteria and patient bed configuration information corresponding to thepatients fall risk criteria are not entering into the healthcare systemserver, it should be understood that this information can be enteredinto the system and employed by the logic 52 in order to determinewhether or not to generate an alert. In step 1 of the flow diagram, ahospital worker can define one or more generic patient fall risk typesand enter these types into a healthcare system of storage on a serversuch as server 11 in FIG. 1. These fall risk types can be identified bythe terms high (high fall risk), medium (medium fall risk), low (lowfall risk), they can be identified in descending numerical order from ahighest to lowest fall risk, or the fall risk type can be define in someother manner. Each generic fall risk type can be associated with a setof generic patient fall risk criteria. The fall risk criteria set caninclude, among other things, the degree to which a patient can balancewhile standing and the type of assistance (cane, walker, hospitalworker) the patient needs in order to remain standing, it can includewhether the patient has any broken limbs, and it can includephysiological measures such as whether the patient has vertigo. Eachfall risk type can be associated with a minimum bed configuration whichis comprised of such things as whether one or more bed rails are up ordown, the tilt angle of the bed and the height of the bed above thefloor level. In step 2, a hospital worker can evaluate whether or not apatient is at risk or falling, and if they are the process proceeds toStep 4, otherwise the process ends at step 3. In Step 4, the hospitalworker can evaluate the degree to which the patient is at risk offalling and assign them to one of the fall risk types entered into thesystem in Step 1. The assigned risk type can then be entered into thepatients EMR. At this point, a healthcare system has information that isnecessary in order to generate an alert indicating that a patient may beat risk of falling at some point in the future.

Continuing to refer to FIG. 6, in Step 5 of the process the logic 52 canexamine a patient's fall risk profile stored in the patient's EMR inorder to determine the patients fall risk type. Based upon the fall risktype, the logic 52 can then, in Step 6, look up minimum bedconfiguration information stored in the table/record described withreference to FIG. 3A. Next, in Step 7 the logic 52 can then examine thecurrent bed configuration state described with reference to FIG. 3D, andcompare this current state to the minimum bed configuration informationdetected as the result of Step 6. Then, in Step 8 the logic 52 canemploy information detected in Step 7 to determine whether a patient iscurrently in their bed, and if not the process proceeds to Step 9 and noalert is generated. On the other hand, if in Step 8 the logic 52determines that a patient is in their bed, the process proceeds to Step10 where the state of the current bed configuration detected in Step 7is compare to the minimum bed configuration for that patient detected inStep 6. If, in Step 11, the comparison performed in Step 10 determinesthat the current bed configuration does not meet the minimum bedconfiguration necessary to adequately protect the patient from fallingout of the bed (i.e. the value of the comparison is greater than apre-determined threshold value), the process proceeds to Step 13 and analert is generated and sent to a call station or directly to a hospitalworker. On the other hand, the process proceeds to Step 12 if the resultof the comparison performed in Step 10 indicates that the current bedconfiguration does meet the minimum configuration necessary to preventthe patient from fall out of the bed.

Software for remotely setting up parameters to be monitored at the bedand monitoring the parameters, which could be for example a thin clientor fat client application, reference is made to co-pending patentapplication Ser. No. 61/790,823, filed on even date herewith, entitledPATIENT SUPPORT APPARATUS WITH REMOTE COMMUNICATIONS (Attorney Docket143667.153339 (STR03 P414).

Accordingly, the present invention provides a healthcare system thatproactively alerts healthcare workers to a bed configuration change thatelevates a patient's risk, for example, of falling out of their bed, orfalling while attempting to enter their bed. With the knowledge that apatient is currently in their bed or not in their bed, knowing thepatient's condition or risk profile, knowing the minimum hospital bedconfiguration associated with the patients risk profile, and knowing thecurrent bed configuration state, the healthcare system can generate anotification, such as an alert to one or more healthcare workers,indicating that the patient's risk of injury is elevated above anacceptable level. More specifically, the present invention can provide ahealthcare system that can include a patient risk processing functionthat operates to compare a current patient bed configuration to aminimum bed configuration corresponding to a patient's condition or riskprofile, and if the current bed configuration does not meet the minimumbed configuration (less than the minimum configuration), then an alertcan be generated by the healthcare system for transmission to one ormore healthcare workers. After receiving the alert, the healthcareworker can modify the current bed configuration to meet the minimum bedconfiguration and the healthcare system can either clear the previouslytransmitted alert and/or it can send another alert indicating that thebed configuration has been corrected. With the knowledge that thecurrent configuration of a patient's hospital bed places them in anelevated risk of injury, accidental patient injuries can be mitigated orprevented.

Therefore, it will be understood that the embodiments shown in thedrawings and described above are merely for illustrative purposes, andare not intended to limit the scope of the invention which is defined bythe claims which follow as interpreted under the principles of patentlaw including the doctrine of equivalents.

The above description is that of current embodiments of the invention.Various alterations and changes can be made without departing from thespirit and broader aspects of the invention as defined in the appendedclaims, which are to be interpreted in accordance with the principles ofpatent law including the doctrine of equivalents. This disclosure ispresented for illustrative purposes and should not be interpreted as anexhaustive description of all embodiments of the invention or to limitthe scope of the claims to the specific elements illustrated ordescribed in connection with these embodiments. For example, and withoutlimitation, any individual element(s) of the described invention may bereplaced by alternative elements that provide substantially similarfunctionality or otherwise provide adequate operation. This includes,for example, presently known alternative elements, such as those thatmight be currently known to one skilled in the art, and alternativeelements that may be developed in the future, such as those that oneskilled in the art might, upon development, recognize as an alternative.Further, the disclosed embodiments include a plurality of features thatare described in concert but which can be used independently and/orcombined with other features. The present invention is not limited toonly those embodiments that include all of these features or thatprovide all of the stated benefits, except to the extent otherwiseexpressly set forth in the issued claims. Any reference to claimelements in the singular, for example, using the articles “a,” “an,”“the” or “said,” is not to be construed as limiting the element to thesingular.

I claim:
 1. A notification system comprising: a patient support having aconfiguration; a patient support monitoring system, the patient supportmonitoring system operable to generate multiple notification levels; anda patient's condition or risk factor associated with a patient stored insaid patient support monitoring system; wherein, based on the patient'scondition or risk factor, said patient support monitoring system isconfigured to select or determine a set of appropriate patient supportconfigurations as a default configuration for the patient and to detectand monitor when the patient support configuration is unsuitable for thepatient based on the default configuration and to generate anotification at one of the notification levels of an unsatisfactoryconfiguration of the patient support when the patient supportconfiguration is unsuitable for the patient based on the defaultconfiguration based on the patient's condition or risk factor.
 2. Thenotification system according to claim 1, wherein said patient supportmonitoring system is configured to allow a user to select a notificationlevel from the notification levels.
 3. The notification system accordingto claim 1, wherein the patient support monitoring system is configuredto generate a high priority notification level, a medium prioritynotification level, and a low priority notification level.
 4. Thenotification system according to claim 1, wherein said patient supportmonitoring system is configured to designate a notification level fromthe notification levels based on the patient's condition or risk factor.5. The notification system according to claim 1, wherein the patientsupport monitoring system is configured to automatically select ordetermine a set of appropriate patient support configurations orcriteria as default configurations or criteria for the patient.
 6. Thenotification system according to claim 1, wherein said patient supportmonitoring system is configured to allow a person to select or enter thepatient's condition or risk factor in said patient support monitoringsystem for the patient.
 7. The notification system according to claim 6,wherein said patient support monitoring system is configured to allow aperson to remotely select or enter the patient's condition or riskfactor in said patient support monitoring system.
 8. The notificationsystem according to claim 1, wherein the patient support monitoringsystem comprises a network interface, and the network interface operableto communicate with a hospital network or healthcare system.
 9. Thenotification system according to claim 8, wherein the patient supportmonitoring system further comprises one or more sensors for detectingthe patient support's configuration, the network interface beingoperable to send information from the sensor or sensors to the hospitalnetwork or healthcare system.
 10. The notification system according toclaim 1, wherein the notification comprises a mobile alert or a pop-updisplay.
 11. A notification system comprising: a patient support havinga configuration; a patient support monitoring system, the patientsupport monitoring system comprising one or more sensors for detectingthe patient support configuration or an event at the patient support,the patient support monitoring system being operable to send informationfrom the one or more sensors to a network or system remote from thepatient support; and a patient's condition or risk factor associatedwith a patient, the patient's condition or risk factor accessible by thepatient support monitoring system; wherein, based on the patient'scondition or risk factor, the patient support monitoring system isconfigured to automatically select or determine a set of appropriatepatient support configuration as a default configuration for the patientand detect and monitor when the patient support configuration isunsuitable for the patient based on the default configuration and togenerate a notification of an unsatisfactory configuration of thepatient support when the patient support configuration is unsuitable fora given patient based on the default configuration based on thepatient's condition or risk factor.
 12. The notification systemaccording to claim 11, wherein said patient's condition or risk factoris stored in said patient support monitoring system.
 13. Thenotification system according to claim 11, wherein the patient supportmonitoring system comprises a patient support monitoring system remotefrom said patient support.
 14. The notification system according toclaim 11, wherein the patient support monitoring system comprises anetwork interface, said network interface in communication with the oneor more sensors at said patient support.
 15. The notification systemaccording to claim 14, in combination with a hospital network or ahealthcare system, the network interface is in communication with thehospital network or the healthcare system.
 16. The notification systemaccording to claim 11, wherein the patient support monitoring system isconfigured to receive the patient's condition or risk factor.
 17. Thenotification system according to claim 11, wherein said patient supportmonitoring system is configured to allow a person to select or enter thepatient's condition or risk factor in said patient support monitoringsystem for the patient.
 18. The notification system according to claim17, wherein said patient support monitoring system is configured toallow a person to remotely select or enter the patient's condition orrisk factor in said patient support monitoring system.
 19. A method ofnotifying relative to a patient support having a configuration, saidmethod comprising: monitoring a patient support, the patient supporthaving a configuration; providing a patient's condition or risk factor;based on the patient's condition or risk factor, automatically selectingor determining a set of appropriate patient support configuration as adefault configuration; comparing the patient support's configuration oran event at the patient support to the default configuration; andgenerating a notification of an unsatisfactory configuration when thepatient support configuration is unsuitable for a given patient based onthe default configuration, wherein the generating the notificationincludes generating a notification level.
 20. The method of notifyingaccording to claim 19, further comprising generating a notification of asatisfactory configuration when the patient support's configuration issuitable for a given patient based on the patient's condition or riskfactor.
 21. The method of notifying according to claim 19, furthercomprising storing the patient's condition or risk factor in a patientmonitoring system at the patient support.
 22. The method ofnotifying_(—) according to claim 19, wherein said monitoring a patientsupport includes remote monitoring the patient support.
 23. The methodof notifying_(—) according to claim 19, further comprising entering orselecting the patient's condition or risk factor.
 24. The method ofnotifying_(—) according to claim 19, wherein said monitoring a patientsupport includes monitoring one or more activities at the patientsupport.